Android系统架构 —— R文件

Posted on | In

Android通过AAPT(Android Asset Packing Tool)将各种资源集成打包并生成索引文件，即R文件。做模块化或编译优化相关工作时，需要对R文件有更多的了解，比如library module中的资源需要加resourcePrefix，做增量编译时可以只编译application module中的R文件等等。

application和library module中R文件的区别

结论：

  • application module中的R文件的资源声明字段都是以常量形式存在，编译后使用到的资源字段以常量值的方式编译进class中。
  • library module中的R文件的资源声明都是以变量形式存在，编译后使用到的字段会以代码引用方式编译进class中。

​

举个例子：

application module:

在application module中新建MainActivity，布局文件是activity_main.xml。编译后，application module的R文件中可以看到：

1
2
3
4
5
public final class R {
	public static final class layout {
		public static final int activity_main=0x7f09001c;
	}
}

activity_main被final修饰，以常量形式存在。且编译后，这个field在class中的引用会被替换成常量值。

MainActivity.class中R.layout.activity_main会被替换成常量值0x7f09001c，十进制为2131296284。

1
2
3
4
5
6
public class MainActivity extends AppCompatActivity {
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		this.setContentView(2131296284);
	}
}

library module:

在library module中新建SubModuleActivity，布局文件是activity_sub_module.xml。编译后，library module中的R文件是：

1
2
3
4
5
public final class R {
	public static final class layout {
		public static int activity_sub_module = 0x7f0f001d;
	}
}

activity_sub_module没有被final修饰，以变量形式存在。

编译后，SubModuleActivity.class中R.layout.activity_sub_module仍然以变量形式存在，以代码引用方式编译进class中。

1
2
3
4
5
6
public class SubModuleActivity extends AppCompatActivity {
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        this.setContentView(layout.activity_sub_module);
    }
}

试想下，如果library module中的R文件的资源声明也是以常量形式声明的话，代码中的资源引用会被替换成常量值。library module和application module中如果出现同名资源，根据R文件合并规则，该资源最终会以application中的资源为准，这就导致library module中代码里资源的常量值对应不到资源，报Resource NotFoundException。

module中R文件个数

​ 一个module被编译时，会生成一个当前module的R文件，同时，该module依赖的module或aar也会在当前module生成R文件。这种依赖关系也包括跨层的传递依赖。所以，一个module中R文件的个数 = 其依赖的module/aar数量 + 1(自身的R文件)。

​ 同理，application module中包含了整个app所有模块的R.java文件。

举个例子：

demo项目依赖结构：

1
2
3
- app (pkg: com.tools.demo)
 - library (pkg: com.tools.second)
  - third (pkg: com.tools.third)

其中library引用了fresco。

编译后，library模块中不仅包含了自身的R文件(com.tools.second.R)，还包含了依赖的module(third模块)和依赖的aar(fresco)的R文件。

app模块则包含了整个app所有模块的R文件，包括直接依赖(library)和间接依赖(third, fresco)的所有module/aar的R文件。

资源合并规则

APK中的资源主要有3个来源：

  • The main source set (generally located in src/main/res/)
  • Build variant source sets
  • Android libraries (AARs)

​ 一个资源文件的文件名在resource type (anim/drawable/layout/menu..) 和 resource qualifier (比如drawable中的hdpi、value中的语言) 目录内是唯一的话，这个资源就被认为是唯一的。

​ 资源文件冲突时，按照下面的优先级进行合并，低优的资源会被覆盖。

1
build variant > build type > product flavor > main source set > library dependencies

比如：main source set包含以下资源：

  • res/layout/foo.xml
  • res/layout-land/foo.xml

debug build type包含：

  • res/layout/foo.xml

最终APK文件中的res/layout/foo.xml来自debug build type，res/layout-land/foo.xml来自main source set。

build variant：

​ build variant可以认为是build type和product flavor的结合。Gradle 会根据build type和product flavor自动创建build variant，并按照 <product-flavor><Build-Type> 的格式命名这些变体。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
android {
    ...
    defaultConfig {...}
    
    buildTypes {
        debug{...}
        release{...}
    }
    
    productFlavors {
        internal {...}
        googlePlay {...}
    }
}

​ 根据上述配置，gradle会构建以下build variant：

  • internalDebug
  • internalRelease
  • googlePlayDebug
  • googlePlayRelease

参考：

Android Resource merging